Debuggers have long been employed to detect errors during the execution of a computer program. Generally speaking, a debugger is typically employed during program development to allow the developer to step through the source code and to obtain information regarding variables and/or other information about the execution environment in order to assist the developer in pinpointing the source of errors.
In most modem operating systems, such as UNIX, Linux, Windows™ and the like, it is not unusual for multiple processes to be executed in parallel.
Consequently, there is a need for a debugger that can debug multiple processes executing concurrently. Examples of such approaches include, for example, products such as Ladebug™ by the Hewlett-Packard Company of Palo Alto, Calif. and Totalview™ by Etnus, LLC at Natick, Mass.
The single, integrated multi-process debugger is one approach that has been employed in the prior art. FIG. 1 illustrates one prior art multi-process debugger 102, which is employed to debug multiple processes 104, 106 and 108 executing concurrently on a computer system. Multi-process debugger 102 is typically a single integrated program, which is typically created from scratch for the purpose of debugging multiple concurrently executing processes.
It has been found, however, that the approach of FIG. 1 has certain disadvantages. For example, since multi-process debugger 102 is responsible for debugging multiple concurrently executing processes, multi-process debugger 102 tends to be a large, complicated program. Further, because multi-process debugger 102 is a single program executing as a single thread, it cannot fully take advantage of the parallelism offered by modem operating systems. As an example, multi-process debugger 102 is constrained by the inherent limit on space/memory associated with a single executing process.
Multi-process debugger 102 also tends to be unreliable in that if it encounters a problem while debugging one of the processes, e.g., process 104, multi-process debugger 102 may crash or halt execution, thereby impacting the debugging with respect to other processes, e.g., processes 106 and 108. As another example, if one of the processes being debugged, for example, process 104, requires a lot of attention in terms of signals or breakpoint hits, multi-process debugger 102 may not have sufficient resource left over to efficiently debug processes 106 and 108.
FIG. 2 shows another approach wherein a user interface 202 is employed to facilitate communication between a user 200 and multiple debuggers 204, 206, and 208, each of which is responsible for debugging a respective process 210, 212, and 214. In the case of FIG. 2, debugger 204, 206, and 208 may represent different instantiations of the same debugger. User interface 202, which may represent either a graphical user interface or a command line interface, is typically created from scratch and includes control logic for interpreting commands from user 200 and formatting those commands into the appropriate format to send to one of the debuggers 204, 206, and 208. Further, user interface 202 also contains logic to parse outputs from debuggers 204, 206, and 208, and format the information received from the debuggers to transmit to user 200.
Although the arrangement of FIG. 2 can better take advantage of the parallelism offered by modem operating systems and processors, there remain disadvantages. For example, the logic required for performing the aforementioned interpreting, parsing, and formatting tends to be complex and thus require a substantial amount of time and effort to develop. Furthermore, the complexity of an additional piece of code that is external to the core of the various debuggers themselves poses a reliability risk to the overall debugging apparatus.